Authenticated Mode Control

ABSTRACT

Methods and systems for authenticated mode control in controlled devices are disclosed. A method for changing a mode in a controlled device from a current mode includes selecting one of several available key derivation functions based on a target mode, generating a target mode specific root key using a global root key and the selected key derivation function, and the use of that root key to affect a change of the controlled device to a target mode. Corresponding devices and systems are also disclosed. In one embodiment, the methods are applicable to a cable television distribution system and the changing of the operating mode of a set top box from one conditional access provider to another.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. Non-Provisional applicationSer. No. 12/385,258 filed Apr. 2, 2009, which is hereby incorporated byreference in its entirety.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates in general to authentication, and inparticular to authenticated changing of modes in controlled devices.

2. Background Art

Broadcast media services, in general, are operated according to a modelwhere a service provider receives programming content from one or morecontent providers at a service provider facility. The service providerthen distributes that programming content, possibly after additionalprocessing, to numerous subscribers over a media distribution network.The service provider can be a large multi service operator (MSO) thatprovides cable television as a broadcast media service. As thetechnologies related to multimedia and data transmission networksimprove, and also as technologies such as high definition televisiondisplays that enhance the corresponding user experience improve,broadcast media services are relied on to distribute an increasingamount of content. The media distribution networks of MSOs are utilizedto distribute an increasingly substantial portion of the digital contentthat flows into homes and businesses. The digital content includestelevision programming, video on demand, pay-per-view content, music,interactive content, games, educational content, remote monitoringservices, etc.

The service provider typically operates the facility in which contentfrom various sources is received, aggregated, processed, anddistributed. The service provider facility that distributes content overa service provider network, such as a cable television network, isgenerally referred to as a headend. In many instances, the serviceprovider also provides equipment, such as a set-top box (STB), to beplaced at the premises of each subscriber. The STB is, in general, acontrolled device that is controlled by the service provider from theheadend of the corresponding media distribution network. The STBincludes the functionality to receive content transmitted from theservice provider headend, and to descramble and/or decrypt that content.The subscriber can, and usually does, couple at least one device such asa television to the STB.

An STB may include other capabilities in addition to descrambling and/ordecrypting. For example, many STBs enable interactivity for the user,such as to order pay per view movies, to enable personal video recordingand viewing, and to use on demand viewing capabilities, etc.

The pirating of programming content by third parties and theunauthorized use of content by subscribers are significant concerns toservice providers. Conditional access is a framework used in manybroadcast media distribution systems to prevent or reduce the piratingand unauthorized use of content. A service provider engages the servicesof a conditional access provider to scramble and/or encrypt content,such as programming content, before transmission over the mediadistribution network, and to descramble and/or decrypt that content atan STB of an authorized subscriber.

The keys (i.e., cryptographic keys) used for scrambling/descramblingand/or encryption/decryption may be generated and/or verified by theconditional access provider. The strength of the content protection isto a substantial extent dependent on the secrecy of the keys andcharacteristics of the keys and algorithms used forencryption/decryption and/or scrambling/descrambling. In addition to thecryptographic strength of each key, the secrecy of the keys is also ofgreat importance.

In a typical conventional broadcast media distribution network a singleconditional access provider protects the programming content that isdistributed. Also, STBs are manufactured and/or initialized to bespecific to a particular service provider and conditional accessprovider. In a typical scenario, a conditional access provider willcreate and/or otherwise obtain one or more unique keys for each new STBthat is manufactured for deployment in a network serviced by thatconditional access provider. The collection of these key and STB pairsis often referred to as the conditional access provider's key database.The key database is accessible to the service provider's headend, andtherefore the one or more keys that correspond to each STB are known tothe headend.

Typically, a conditional access provider also provides a black boxdevice that is used to initialize each STB at the time of manufacturewith one or more keys that are to be subsequently used in the STB whenthe STB is activated in a network of a service provider. One or morekeys from the black box device can be written into the one timeprogrammable (OTP) memory of each STB. For example, keys from the blackbox device can be securely written to a system-on-a-chip (SoC) that isthen included in an STB. In some cases, the keys are written into theOTP memory in an obfuscated form to make unauthorized access to the keysmore difficult, and each key is de-obfuscated only at the time of use.

It may be desirable to have STBs that are usable in the networks ofmultiple service providers. Particularly, as STBs become capable of muchmore functionality than the decoding and delivering of received content,subscribers can increasingly seek to have STBs that can operate withmultiple service providers and/or multiple media distribution networks.Also, the conditional access provider servicing an STB can change due toseveral situations, such as, the service provider switching conditionalaccess providers, another conditional access provider operating in thesame network, or the STB being moved to a new network.

When the conditional access provider is changed, an STB can no longerreceive programming content in a manner useful to the subscriber unlessanother conditional access provider's keys are made available to theSTB. To be able to receive programming content protected by more thanone conditional access provider, conventionally all conditional accessproviders that want to send content to an STB would be required to storetheir corresponding key or keys in the STB at the time of manufacture.For example, an OTP memory in an STB can be programmed with the keydatabases of each conditional access provider that want to provideservices to that STB. Also, each headend would have access to the keydatabases of each conditional access provider that can provide servicesto any STB in the corresponding network. This approach generally leadsto a conditional access provider having to share its keys, particularlythe encryption keys, with other conditional access providers. Indeployed networks the sharing of keys also takes place due to theinability to store more than a very limited number of keys in the memoryof a single SoC or STB, and as a result of the need to support an STBwhen it change over to a conditional access provider for which the STBdoes not have preprogrammed key information. Such sharing of keys canexpose one conditional access provider to the weaknesses in keymanagement of another conditional access provider.

Therefore, although enabling an STB to operate with multiple conditionalaccess providers provide numerous advantages, the sharing of encryptionkeys between conditional access providers unnecessarily exposes a mediadistribution system to the weaknesses of the less secure conditionalaccess providers. For example, if conditional access provider A has itskey database exposed to an attacker, that attacker may now be able toattack a second service provider network if the exposed keys are sharedwith a conditional access provider who services the second serviceprovider network. Clearly, methods and systems to enable an STB toreceive programming content through multiple conditional accessproviders without sharing of encryption keys would be useful.

BRIEF SUMMARY OF THE INVENTION

Methods and systems for authenticated mode control in controlled devicesare disclosed. In one embodiment a method for changing a mode in acontrolled device from a current mode includes selecting a target keyderivation function from a plurality of key derivation functions wherethe target key derivation function corresponds to a target mode,generating a target root key by providing a global root key as input tothe target key derivation function, and changing the mode in thecontrolled device from the current mode to the target mode using one ormore keys from a key ladder that is initialized with the target rootkey.

A method to change a mode from a current mode, according to anotherembodiment includes, selecting a current key derivation function from aplurality of key derivation functions where the current key derivationfunction corresponds to the current mode, generating a current root keyby providing a global root key as input to the current key derivationfunction, and changing the controlled device from the current mode to atarget mode using one or more keys from a key ladder that is initializedwith the current root key.

Another embodiment is a controlled device including a memory configuredwith at least one global root key, a key derivation function moduleconfigured with a plurality of key derivation functions where a firstkey derivation function from the plurality of key derivation functionsis assigned to a first mode and where a second key derivation functionfrom the plurality of key derivation functions is assigned to a secondmode, a key generator module configured to generate a root key using theglobal root key and the first key derivation function, and a keymanagement module configured to use the root key to obtain one or moresecret keys from messages received from an authorizing entity.

Yet another embodiment is a media delivery system having a mediadistribution network, a media distribution center, and at least onecontrolled device. The media distribution center includes a global rootkey database having at least one global root key that is known to one ormore conditional access systems, at least one key derivation function,wherein the key derivation function corresponds to one of the one ormore conditional access systems, a key generator module configured togenerate an encryption key using the at least one global root key andthe at least one key derivation function; and a mode controller moduleconfigured to generate a mode authorization request, wherein the modeauthorization request is encrypted using the encryption key. Thecontrolled device includes a memory having the at least one global rootkey, a key derivation function module having a plurality of keyderivation functions including said key derivation function, a keygenerator module configured to generate a decryption key using the atleast one global root key and said key derivation function, and a modecontrol module configured to verify a mode request using said modeauthorization message, and to initiate a mode change according to theverified mode request.

Further embodiments, features, and advantages of the present invention,as well as the structure and operation of the various embodiments of thepresent invention, are described in detail below with reference to theaccompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS/FIGURES

The accompanying drawings, which are incorporated in and constitute partof the specification, illustrate embodiments of the invention and,together with the general description given above and the detaileddescription of the embodiment given below, serve to explain theprinciples of the present invention. In the drawings:

FIG. 1 illustrates media distribution systems according to an embodimentof the present invention.

FIG. 2 illustrates a media distribution center, according to anembodiment of the present invention.

FIG. 3 illustrates a controlled device, according to an embodiment ofthe present invention.

FIG. 4 illustrates a method for causing a change of conditional accessmodes in controlled devices as implemented at a headend, according to anembodiment of the present invention.

FIG. 5 illustrates a method for deriving a root key at a headend,according to an embodiment of the present invention.

FIG. 6 illustrates a method for causing a change of conditional accessmodes in controlled devices as implemented in a controlled device,according to an embodiment of the present invention.

FIG. 7 illustrates a method for deriving a root key at a controlleddevice, according to an embodiment of the present invention.

FIG. 8 illustrates a state machine implemented in a controlled device tochange conditional access modes, according to an embodiment of thepresent invention.

FIG. 9 illustrates another state machine implemented in a controlleddevice to change conditional access modes, according to an embodiment ofthe present invention.

DETAILED DESCRIPTION OF THE INVENTION

While the present invention is described herein with illustrativeembodiments for particular applications, it should be understood thatthe invention is not limited thereto. Those skilled in the art withaccess to the teachings provided herein will recognize additionalmodifications, applications, and embodiments within the scope thereofand additional fields in which the invention would be of significantutility.

Overview

This disclosure presents a novel approach to the authenticated changingof operating modes in controlled devices. A particularly advantageoususe of the novel approach described herein may be to have a singlecontrolled device, such as a set-top box (STB), that is capable ofoperating in the networks of multiple service providers and receivingconditional access protected content from multiple service providersand/or multiple conditional access providers. Numerous otheradvantageous uses of the novel approach exist, some of which aredescribed herein.

The “mode” or “operating mode” of a controlled device, as used herein,determines whether the controlled device can receive services and/orcontent in an authorized manner from a controller such as a serviceprovider and/or conditional access provider. For example, in modeMODE-A, a controlled device can receive services and content only fromconditional access provider A, and in mode MODE-B, only from theconditional access provider B. As described above, conventionalapproaches to changing operating modes of controlled devices in anauthenticated manner involve the sharing of keys used for encryptionbetween conditional access providers. Other conventional approaches useadd-on modules to the STB such as Smart Cards containing security keysthat can be swapped-in when conditional access providers change.Embodiments of the present invention can substantially reduce thesecurity risks associated with the authenticated changing of modes incontrolled devices. For example, embodiments of the present invention donot require that secret keys of one controlling entity are shared with asecond entity that wishes to control the same controlled device. Also,embodiments of the present invention can be implemented in a STB withoutthe need for relatively expensive add-on cards etc. As the volume andvariety of content that are distributed over media distribution networksgrow, the provision of conditional access and the flexibility inconfiguring controlled devices to receive conditional access protectedcontent becomes more important in enabling service providers to ensurethat their programming content is not pirated and/or used inunauthorized ways.

For purposes of clarity, the description below is primarily based onmedia distribution systems in general and cable television distributionsystem in particular. Frequently described example embodiments includeconditional access provision for a cable television system. A person ofordinary skill in the relevant arts will understand that embodiments ofthe present invention can also include systems other than mediadistribution systems, such as remote surveillance systems, remotelymanaged server or processing systems, and various other systems thatinclude devices that are remotely managed and/or controlled. Forexample, an embodiment of the present invention can enable a monitoringunit located in a customer home to change its internal operating modesuch that in case of a security alarm it will dial out to a newlyconfigured alarm monitoring service instead of the initially configuredservice.

A Media Distribution System

FIG. 1 shows two media distribution systems 100 and 150, according to anembodiment of the present invention. Media distribution systems 100 and150 can include cable television distribution systems, satellitetelevision distribution systems, and distribution systems for othercontent such as multimedia, games, or interactive content. In oneembodiment, media distribution system 100 includes a headend 110, amedia distribution network 111, and one or more set-top boxes (STB) 120,121, and 122. Content, such as cable television programming, can bereceived at headend 110 from content providers 140 and 141 overinterfaces 112 and 113, respectively. Each STB can have one or morecoupled devices for presenting content received from media distributionsystem 100 to a subscriber. For example, receiver 130 can be coupled toSTB 120 through an interface 114. Conditional access providers 145 and146 are coupled to headend 110 through interfaces 116 and 117,respectively.

For example, media distribution system 100 can be a cable televisiondistribution system owned by one cable television service provider,while media distribution system 150 can be a satellite televisiondistribution system owned by one satellite television service provider.Cable television service providers and satellite television serviceproviders, in general, own their respective media distribution networks111 and 161. Content providers, such as content providers 140, 141, and143, provide content that is distributed by cable television serviceproviders and satellite television service providers over theirdistribution systems 100 and 150, respectively.

Content providers 140, 141, and 143 can include various contentproducers and content distributors such as entertainment and newsstudios. For example, in one embodiment, television media distributionsystems 100 and 150 can both be provided with content from newsproducers such as Cable News Network (CNN) and other entertainment andeducational programming providers such as Public Broadcasting System(PBS).

Each content provider can provide its content to one or more mediadistribution systems. For example, content providers 140, 141, and 143can provide their content to one or more media distribution networks,such as media distribution networks 100 and 150, through connectionssuch as connections 112, 113, 162 and 163. Connections 112, 113, 162,163 can include one or more network communication technologies such asEthernet, IEEE 802.11, Digital Subscriber Line (DSL), leased linetelecommunications circuits, and such other connection technologies andprotocols that are used to distribute audio, video, and other data.

Headends 110 and 160 are typically service providers' facilities thatinclude the functionality to receive content from various contentproviders and to transmit the content over media distribution networks111 and 161, respectively. In one embodiment, cable television providerheadend 110 includes devices to decode, process, store, and distributeaudio, video and other content received from content providers 140 and141. Headend 110 is further described in relation to FIG. 2 below. Also,in an embodiment, headend 160 includes functionality similar to headend110, but is configured to distribute the content it receives fromcontent providers 141 and 143 over another media distribution network161. For example, media distribution network 161 can be a satellitenetwork.

Media distribution network 111 couples headend 110 to a plurality ofcontrolled devices such as STBs 120, 121, and 122. Media distributionnetwork 161 couples headend 160 to a plurality of devices such as STBs170 and 171. Media distribution networks 111 and 161 can include a mediadelivery network such as cable television network of coaxial cable,fiber-optics, or hybrid fiber coax, a satellite broadcast network,Ethernet, IEEE 802.11, Digital Subscriber Line (DSL), leased linetelecommunications circuits, and such other connection technologies andprotocols that can be used to distribute audio, video, and other data. Aperson of ordinary skill in the art understands that media distributionnetworks 111 and 161 can comprise a variety of network topologies,technologies, and devices, while being consistent with the teachings ofthe present disclosure.

STBs 120, 121, 122, are controlled devices, typically remotely located,that receive content, such as cable television programming content, fromcorresponding headends 110 or 160. In some embodiments of the presentinvention, controlled devices include STBs located in subscriberpremises. For example, cable television networks can require a STB ateach subscriber premises to receive programming content, to decodeprogramming content, to enable the subscriber to interact with the cabledistribution network, and/or to facilitate various other services to thesubscriber. The STB is, in general, controlled by the correspondingheadend, for example, to enable or disable various services from thecable television provider to the subscriber.

To facilitate the communication between a headend and a controlleddevice coupled to that headend one or more communication protocols maybe used. For example, Digital Video Broadcasting (DVB) is a set ofstandards for broadcasting digital video in systems such as cabletelevision systems and satellite television systems. Digital VideoBroadcasting-Conditional Access (DVB-CA) is a related standard thatdefines messages and interactions between a headend conditional accessprovider and the conditional access related hardware or software in acontrolled device. The DVB-CA standard, for example defines EntitlementManagement Messages (EMM) and Entitlement Control Messages (ECM) thatflow from the headend to controlled devices in the correspondingnetwork. EMM are used to communicate user level conditional accessinformation and authorizations, and ECM are used to communicate programlevel information and authorizations. For example, according to anembodiment of the present invention, messages sent from headend 100 toSTB 120 to cause STB 120 to change mode can include EMM and ECM. Acontrolled device, such as an STB, is further described in relation toFIG. 3 below.

Each controlled device, in general, is coupled to one or more receivingdevices that present the content received by the control device to asubscriber. For example, STB 120 is connected to a receiver 130 and STB171 is connected to receiver 180. Receivers 130 and 180 can includetelevisions or other display devices, audio playback devices, audio orvideo recording devices, gaming devices, or computers. In should also benoted that in some embodiments, controlled device or STB 120 can bemerged with receiver 130. Receivers 130 and 180 can be connected to therespective STB in one or more of several connection devices such as aHigh Definition Media Interface (HDMI), Digital Visual Interface (DVI),Firewire, Ethernet, IEEE 802.11, and the like.

Conditional access providers 145 and 146 provide media distributionsystem 100 with content protection so that subscribers can beappropriately charged for services and content. For example, withrespect to pay per view video, the conditional access provider enablesthe appropriate scrambling and/or encrypting of the pay per viewprogramming content such that it is only available to subscribers whoduly purchased the content. Conditional access providers can also enablethe authentication of subscribers and associated STBs that are connectedto the network of a service provider. Content, such as programmingcontent, that are protected by a conditional access provider is referredto herein as conditional access protected content. It should be notedthat in some embodiments, conditional access providers and serviceproviders can be the same entities. The conditional access provider mayalso be considered, in general, as an authorizing entity that authorizesa particular mode in a controlled device.

Conditional access providers can obtain security certificates and/orsecurity keys (e.g., global root key described below) from a centralsecurity authority. In some embodiments, the generation of keys can bedone by the respective conditional access providers while a centralauthority provides the service of authenticating the validity of each ofthe conditional access providers and their generated keys. In yet otherembodiments, keys are generated and authentication is provided by aconditional access provider and no central authority is required. Ingeneral, each conditional access provider services a media distributionnetwork with separate unique keys. For example, even if conditionalaccess provider 145 services both media distribution system 100 and 160,separate sets of unique keys can be used for each distribution system.

The functionality to store keys provided by conditional access providersand the functionality to perform such scrambling/descrambling and/orencryption/decryption as necessary to provide are, in general, locatedon the headend and on each controlled device. Interfaces 115, 116, and117 can provide an electronic or other coupling to a facility of theconditional access provider, for example, for purposes of transferringkeys.

Each STB 120, 121, 123, 170 or 171, is authorized to receive and decodeconditional access protected content from one or more conditional accessproviders. In general, each STB is configured for one or more mediadistribution networks and/or conditional access providers, for example,by writing one or more unique keys in to the STB's one time programmable(OTP) memory at the time of manufacture and providing one or more keyderivation functions unique to each conditional access provider. Furtherdescription of preconfiguration of keys in each STB is described inrelation to FIG. 3.

A Media Distribution Center

FIG. 2 illustrates a media distribution center, such as headend 110,according to an embodiment of the present invention. Headend 110 caninclude an audio/video processor 202, a message processor 204, amultiplexer 206, a headend mode controller 208, a headend key generator210, a random value generator 212, an encrypter/decrypter 214, a headendkey derivation function device 226, and a headend global root keydatabase 228. Headend 110 can have an input interface 230 that couplesheadend 110 to various audio/video programming content sources, and oneor more input interfaces 232 that, for example, couple headend 110 tocontrolled devices in media distribution system 100 as well as varioussources of programming content. An interface 234 couples headend 110 tomedia distribution network 111. A person of ordinary skill in the artwill understand that headend 110 can include various other devicesincluding, for example, processors, storage devices, recording devices,etc.

Audio/video processor 202 can include one or more audio/video contentprocessing devices. Audio/video processor 202 includes the functionalityto receive and descramble/decrypt audio and video content from variouscontent generation sources and process such input into programmingcontent, and the functionality to encrypt programming content fordelivery over media distribution network 111. For example, audio/videoprocessor 202 can include functionality to insert advertising contentinto the stream of programming content, to perform any content formatchanges and/or compression, and to encrypt the content before theprogramming content is transmitted out to media distribution network111.

Message processor 204 can include one or more message processingdevices.

Message processor 204 includes the functionality to receive and respondto messages from controlled devices, to generate messages in response toinstructions from headend mode controller 208. Messages from controlleddevices can include requests for conditional access keys and statusmessages. Headend mode controller 208 can direct message processor 208to generate messages to be transmitted to one or more controlled devicesto effect a change of conditional access modes.

Multiplexer 206 includes the functionality to combine the stream ofprogramming content and control messages into a form that can betransmitted over interface 234 into media distribution network 111.Multiplexer 206 can implement one or more multiplexing methods such asinserting messages to be transmitted in selected locations in anaudio/video programming stream, based on characteristics includingcharacteristics of media distribution network 111.

Headend mode controller 208 includes the functionality to cause one ormore controlled devices to change their conditional access modes inresponse to messages from headend 110. In one embodiment, headend modecontroller 208 generates one or more messages, such as, a mode requestmessage, a mode authorization message, and a key distribution message,that is to be transmitted to an identified controlled device. The keysto be transmitted, and the keys needed for encryption etc., can begenerated using headend key generator 210, and random values used formessage authentication can be generated using random value generator212.

Headend key generator 210 can include functionality to, for example,derive a root key (also referred to herein as KEY-2) specific to a givenconditional access provider using a global root key and a key derivationfunction. Headend key generator 210 can also include functionality togenerate keys with various predetermined characteristics. The encryptionkey (also referred to herein as secret key or KEY-3), for example, canbe generated in headend key generator 210 using a random key generatorwith predetermined cryptographic characteristics. Key generators aregenerally well known in the relevant arts.

Random value generator 212 can provide a random value, such as a randominteger in a specified range or a random string with specifiedcharacteristics, to be used in messages transmitted to a controlleddevice to aid that controlled device in authenticating the messages.Random value generators are generally well known in the art.

Encrypter/decrypter 214 can include one or more devices that provide theability to scramble/descramble and/or encrypt/decrypt various messagesand content. In one embodiment, encrypter/decrypter 214 can encrypt thestream of audio and video programming content to be transmitted out. Thefunctionality to decode or decrypt the incoming content from variouscontent providers can also be provided by encrypter/decrypter 214. Also,encrypter/decrypter 214 can provide encryption for messages that aretransmitted to controlled devices, and for any messages that arereceived at headend 110. Encryption and decryption technology that canbe used in encrypter/decrypter 214 are generally well known, and caninclude one or more of Data Encryption Standard (DES), Triple-DES(TDES), and Advanced Encryption Standard (AES). In some embodiments,encrypter/decrypter 214 can receive keys used for encryption and/ordecryption from headend key generator 210.

Headend global root key database 228 includes global root keys forcontrolled devices, including those controlled devices that arecurrently connected to media distribution network 111. Headend globalroot key database 228 can either be located physically within headend110, or be located remotely such that it can be accessed securely byheadend 110. Headend global root key database 228 can be any data storethat includes one or more global root keys. Global root keys can begenerated by a conditional access provider or a higher conditionalaccess authority or a key generating entity. Typically, each controlleddevice is assigned a unique global root key. The global root key for acontrolled device can be considered a shared secret, i.e., a secretshared between one or more conditional access providers. For example, aglobal root key that is unique to STB 120 can be generated by inputtingthe serial number of STB 120 to a one-way hash function. The global rootkey for a controlled device is shared among all conditional accessproviders and/or media distribution centers that are coupled to, or thatcan be potentially coupled to, that controlled device. Note that hereinthe term “database” is used to refer to a collection of data items anddoes not necessarily imply a database management system.

Headend key derivation function module 226 includes key derivationfunctions that are used in the derivation of the root key that isspecific to each conditional access provider. In one embodiment, headendkey derivation function module 226 includes at least one key derivationfunction from each conditional access provider that can service themedia distribution system 100. A key derivation function, as usedherein, is a cryptographic hash function that takes as input anon-secret value or a shared secret value such as a global root key andproduces a key that is specific to the conditional access provider towhom the key derivation function is assigned. Key derivation functionscan have predetermined characteristics such that keys output from thesekey derivation functions include specified levels of cryptographic“strength” or other features. In general, embodiments of the presentinvention can utilize any secret key derivation functions. A secretone-way key derivation function can be used in some embodiments.

A Controlled Device

FIG. 3 illustrates a controlled device, such as STB 120, that is coupledto a media distribution system such as media distribution system 100. Inone embodiment, STB 120 includes a processor 301, memory 303, storage305, one time programmable (OTP) memory 306, a STB key deriver 308, akey derivation function selector 309, an input interface 312, an outputinterface 314, a demultiplexer 316, an audio/video decoder 318, anencrypter/decrypter 320, an audio/video processor 322, a secondarycontent processor 323, an output formatter 324, an STB mode controller330, and an STB key manager 340. STB 120 can include input interface 312for receiving input, such as programming content and control messages,from headend 110. STB 120 can also include output interface 331 that canbe used for transmitting status and other messages to headend 110, andan interface 333 to a transmit programming content to a receiver such asreceiver 130. Persons ordinarily skilled in the art would recognize thatSTB 120 can contain processing and communicating components (bothhardware and software) other that those shown in FIG. 3. It should benoted that in one embodiment, the STB 120 can represent asystem-on-a-chip implementation of a set-top box.

Processor 301 can include one or more control processors such as centralprocessor units (CPU), graphic processor units (GPU), digital signalprocessors (DSP), field programmable gate arrays (FPGA), or applicationspecific integrated circuits (ASIC). Processor 301 (e.g., the one ormore processors comprising processor 301) can include the functionalityto control the functions of components of STB 120, and to implementlogic, logic blocks, and software modules within STB 120.

Memory 303 can include dynamic or volatile memory such as random accessmemory (RAM). Memory 303 is typically used for holding data, processinglogic, and results during processing. In some embodiments memory 303 canalso be used for storing keys and related data.

Storage 305 can include persistent (non-volatile) memory devices and/orpersistent data storage devices such as disk storage, flash memory, etc.Among its many uses, storage 305 can be used to store keys and relatedinformation.

OTP memory 306, in general, includes a non-volatile memory such as aprogrammable read only memory (PROM). OTP includes the functionality tohold information such as configuration data such as global root keys,authorized mode values, etc. In one embodiment, for example, the globalroot key corresponding to the STB can be stored in OTP memory 306 at thetime of manufacture.

STB key deriver 308 includes one or more key derivation functions (e.g.,key derivation function 1 308 a and key derivation function 2 308 b). Inone embodiment, STB key deriver 308 includes a separate key derivationfunction for each of several conditional access providers. For example,at the time of manufacture, each conditional access provider can providea logic block, hardware circuit, and/or software algorithm implementingits key derivation function, to be integrated into STB 120. Typically,conditional access providers would each distribute the key derivationfunction and related hardware and/or software implementing its keyderivation functions in a manner that substantially maintains thesecrecy of those functions. In an embodiment, based on the requestedconditional access mode, headend 110 dynamically selects a keyderivation function. Likewise, STB 120 can use selector 309 to select akey derivation from the STB key deriver 308 based on the conditionalaccess mode. In an embodiment, selector 309 can be a switch implementedin hardware that can dynamically select a key derivation function. Forexample, based on the requested mode, selector 309 can be switched toenable the key derivation function for the conditional access providercorresponding to that requested mode.

Note that with respect to a particular conditional access provider, itskey derivation function in the headend should correspond to its keyderivation function in the STB. For example, the functional relationshipbetween a particular conditional access provider's key derivationfunctions in the headend and in an STB should be such that the root keyKEY-2 derived at the STB must be usable to decrypt messages encryptedwith the root key KEY-2 derived at the headend. In one embodiment, for aparticular conditional access provider, the key derivation functions inthe headend and STB are identical, and therefore the root keys producedby inputting the same global root key to the key derivation functionsare identical. The use of identical keys for encryption and decryptionis also referred to as symmetric key encryption.

In one embodiment, a global root key retrieved from OTP 306 is input toa selected key derivation function in STB key deriver 308 to derive aroot key specific to a conditional access provider. STB key manager 310can include the functionality of a key ladder, where keys are derived orrecovered at each level based on another (e.g., previously determined)key. For example, in one embodiment, STB manager 340 can implement a keyladder of two levels: a first level in which a conditional accessprovider-specific root key KEY-2 is obtained, and a second level inwhich the root key KEY-2 is used in the recovery of anencryption/decryption key from a message sent by a headend.

Input interface 312 includes functionality to receive programmingcontent and messages from a network, for example, media distributionnetwork 111 through interface 332. Output interface 314 includes thefunctionality to output messages and other data, for example, toheadend. 110 through interface 331 and media distribution network 111.In addition to electrical components, input interface 312 and outputinterface 314 can also include logic implementing of one or moreprotocols to receive programming content and to exchange messages withheadend 110. For example, input interface 312 and output interface 314can implement a version of the DOCSIS protocol standard, or the DVB-CAprotocol standard, in collaboration with its counterpart interfaces inheadend 110. Input interface 312 and output interface 314 can beimplemented using well known interface technology.

Demultiplexer 316 receives the incoming data stream from input interface312, and demultiplexes the data stream into audio/video programmingstream and messages and/or other content. Demultiplexer technology iswell known in the relevant arts. The audio/video programming content isinput to audio/video decrypter 318 and the messages and other contentare directed to secondary content processor 323. Secondary contentprocessor 323 can use encrypter/decrypter 320 to decrypt any encryptedmessages. In one embodiment EMM messages, such as encrypted modeauthorization messages, can be passed by secondary content processor 323to STB mode controller 330. Both devices 318 and 320 includefunctionality to decrypt the incoming streams using one or more ofdecryption methods. In one embodiment, devices 318 and 320 will beprovided with decryption keys by STB key manager module 340. Forexample, in one embodiment, key manager 340 periodically receivesencrypted code words (keys) with which incoming programming areencrypted. Based on the currently authorized conditional access mode,key manager 340 may decrypt the code words and provide the decryptedcode words to audio/video decrypter 318 to decrypt incoming programmingcontent.

STB mode controller 330 includes functionality to receive incoming modecontrol messages, for example, mode requests, key messages, and modeauthorization messages from headend 110, and implement the appropriatemode changes. STB mode controller can decrypt the messages as necessaryby using encrypter/decrypter 320, either directly or through STB keymanager 340. In one embodiment, STM mode controller 330 implementsprocess 800 and/or process 900 (described below) to change the mode ofthe STB 120.

Audio/video processor 322 includes the functionality to perform variousprocessing on the programming content received from decrypter 318,including content filtering, encoding for transmission over interface333, compression, etc. Secondary content processor 323, in oneembodiment, includes the functionality to process messages and/or othercontent such as sub-titles and other text overlays on a video stream.The audio/video programming content from audio/video processor 322 andother content from secondary content processor, are then received atoutput formatter 324 that includes the functionality to performprocessing and formatting specific to interface 333 and/or the receivingdevice, such as receiver 130. Output formatter 324 can output thecontent to interface 333.

Controller for Authenticated Mode Control

FIG. 4 illustrates a process 400 that can be implemented in a mediadistribution center, such as headend 110, to cause one or morecontrolled devices, such as STB 120, to perform a controlled change ofoperating modes. The change of operating mode can be the changing ofconditional access modes. For example, headend 110 may cause STB 120 totransition from a mode where STB 120 has no active conditional accessprovider (MODE-0) to a mode where conditional access provider B (i.e.,CA-B) is the active conditional access provider (MODE-B). In theembodiments described in relation to process 400, headend 110 generatesthree messages—a key message (MKEY), a mode authorization message(MAUTHORIZATION), and a mode request message (MREQUEST)—to cause thechange of mode at STB 120 from MODE-0 to MODE-B. A corresponding processin STB 120 is described with respect to FIG. 6. Further description of astate machine that can be implemented in STB 120 corresponding to theembodiments described here is available in relation to FIG. 8.

Although process 400 is described herein with a particular ordering ofprocessing steps 401-410, it should be noted that different ordering ofsteps, the deletion or addition of certain steps, and changing thefunctionality of one or more steps, are possible while being consistentwith the teachings in this disclosure. Also, although the embodimentsprimarily describe three separate messages that cause the change ofmode, other embodiments of the present invention can include differentmeans by which STB 120 is informed of the necessary instructions andauthorizations to change its conditional access mode. For example, insome embodiments, the content of one or more of the messages MKEY,MAUTHORIZATION, and MREQUEST, can be available to STB 120 through othermeans such as OTP where the information is stored at the time ofmanufacture or initialization of the STB 120, or when a related messageis received from headend 110.

In step 401, headend 110 initiates one or more processes that controlthe change of conditional access modes in STB 120. Headend 110 mayinitiate the one or more processes in response to a received alert thatindicates the need to have STB 120 effect a change of conditional accessmodes. A received alert can, for example, include a message from the STB120 indicating that it has newly connected to media distribution network111, an explicit instruction generated by a user (e.g., an operator fromthe service provider or conditional access provider), or a switch ofconditional access providers in media distribution network 111.

In step 402, headend 110 generates a random value that can subsequentlybe included in messages to STB 120 to aid in the authentication of thosemessages. In one embodiment, the random value is a random integer in apredetermined range. In another embodiment, a random string value of apredetermined length can be generated. The random value generation maybe implemented in random string generator module 212 in headend 110.Methods for generating random numbers and/or random strings according tovarious security criteria are well known in the relevant arts. It shouldbe noted that some embodiments of the present invention may not includea step 402 and/or the generation of a random value, and may use anothermethod to authenticate the messages. For example, in some embodiments noadditional verification may be required of messages due tocharacteristics of the message delivery facilities in the correspondingsystem, such as media distribution system 100. Additional message levelverification and/or authentication using message content may not beneeded if, for example, the underlying communication network, such asmedia distribution network 111, provides a highly reliable messagedelivery platform that can substantially ensure that no attacker caninsert malicious messages that masquerade as one or more of MKEY,MAUTHORIZATION, and MREQUEST messages from the headend 110 to STB 120.

In step 403, a mode request message MREQUEST is generated andtransmitted to one or more controlled devices including STB 120.MREQUEST includes the desired conditional access mode (requested-mode)and is generally transmitted to STB 120 in unencrypted form. MREQUESTalso includes the random value generated in step 402 to aid inauthentication. MREQUEST can be generated in one or more of the modules204 and 208, and be transmitted to STB 120 via interface 234 fromheadend 110.

In step 404, an encryption key (KEY-3) is generated with which tosubsequently encrypt the outgoing mode authorization messageMAUTHORIZATION. Embodiments described in relation to process 400 utilizea key ladder of two levels, i.e., a conditional access provider-specificroot key derived from a global root key, and a key used toencrypt/decrypt the mode authorization message. Other embodiments mayinclude key ladders having different numbers of levels. The key KEY-3with which to encrypt the mode authorization message can be generated bya random key generator. For example, in one embodiment, key generator210 of headend 110 may include a random key generator. Random keygenerators that generate keys according to various specifiedcryptographic properties are well known in the relevant arts.

In step 405 a root key is derived. The root key KEY-2 derived in step404 can be used as the initial key in a key ladder utilized by headend110 and STB 120 for purposes including the changing of conditionalaccess modes. In some embodiments, step 405 can be implemented in amodule such as key generator module 210 of headend 110. The derivationof KEY-2 by headend 110 is described in relation to FIG. 5 below.

In step 406, key distribution message MKEY to distribute KEY-3 isgenerated and encrypted with conditional access provider-specific rootkey KEY-2. MKEY includes KEY-3 in encrypted form. In some embodiments,message processor 204 may utilize encrypter/decrypter module 214 toencrypt the contents of MKEY including KEY-3. The intended purpose ofMKEY is to inform a controlled device such as STB 120, of the key withwhich the mode authorization message is encrypted by headend 110.Therefore, some embodiments in which STB 120 can be informed of theencryption key KEY-3 for encrypting the mode authorization messagethrough other means may not include a separate MKEY message. Forexample, in embodiments that use the root key KEY-2 to encrypt the modeauthorization message, no separate MKEY message is needed because KEY-2can be derived by the STB 120 without a separate message from headend110.

In step 407, the MKEY message is transmitted to STB 120 through, forexample, interface 234 and media distribution network 111.

In step 408, headend 110 can obtain a value associated with theconditional access provider corresponding to the requested-mode, such asan epoch value. An epoch value can be used as an aid to verify theauthentication of a message as well as a mechanism to revoke apreviously configured conditional access mode. An epoch value herein canbe regarded by STB 120 as a monotonically increasing positive integervalue. Each time headend 110 causes a change to a requested-mode,headend 110 can increment the locally-maintained epoch value associatedwith the corresponding conditional access provider and/or key derivationfunction by one. Each time STB 120 changes to the requested-mode asauthorized by headend 110, STB 120 can increment the locally-maintainedepoch value associated with the corresponding conditional accessprovider and/or key derivation function by one. In one embodiment, whenheadend 110 determines that the current mode of STB 120 should berevoked, headend 110 would request STB 120 to write an epoch valuehigher than a predetermined threshold into its OTP memory. This wouldeffectively revoke previously received mode authorization messagesbecause previously received mode authorization messages would have alower epoch value. Thereafter, headend 110 would ensure that themessages it sends have an epoch value equal to or greater than the onein STB 120.

A mode authorization message MAUTHORIZATION is generated in step 409.MAUTHORIZATION includes the conditional access mode for whichauthorization is granted. Some or all of the contents of theMAUTHORIZATION message are encrypted. MAUTHORIZATION can also includeother items such as the random value generated in step 402, and theepoch value obtained in step 408. For example, transmitting the randomvalue generated in step 408 in encrypted form would enable STB 120 tocompare the random string from MREQUEST and MAUTHORIZATION and determinethe authenticity of MREQUEST with substantial certainty. An added levelof verification can be obtained with the epoch value included in theMAUTHORIZATION. Also, the epoch value can be used as a mechanism withwhich to affect a revocation of a conditional access mode in STB 120.The generation and encryption of the MAUTHORIZATION message can beimplemented, for example, in message processor 204 andencrypter/decrypter 214 of headend 110.

In step 410, the encrypted MAUTHORIZATION message is transmitted to STB120 through, for example, interface 234 and network 111.

FIG. 5 illustrates the processing of step 405 in more detail. The mannerin which the root key is derived in embodiments of the presentinvention, enables changing of conditional access modes in controlleddevices without revealing the root keys and/or encryption keys of oneconditional access provider to another.

As described above, a shared global root key is made available toconditional access providers that desire the capability to changeconditional access modes of controlled devices in their associatedservice provider networks. The shared global root key can be unique toeach controlled device. The global root keys can be generated anddistributed to conditional access providers by a higher levelconditional access authority. In one embodiment, a database of allshared global root keys is made accessible to headend 110, where thedatabase includes the global root key for all controlled devices thathave been configured with the key derivation functions of any one of theconditional access providers that provide services over thecorresponding network.

In step 501, headend 110 or more particularly key generator 210, canaccess global root database 228. Using an identifier for STB 120 and insome cases also the conditional access provider corresponding to therequested-mode, headend 110 can determine the global root keycorresponding to STB 120.

The global root key for STB 120 is then provided as input to a keyderivation function assigned to the conditional access providercorresponding to the requested-mode. Key derivation functions for eachof the potential conditional access providers can be made available inheadend key derivation function module 226. Note that embodiments of thepresent invention can include key derivation functions in the headendimplemented in hardware, software, or any combination thereof. Keyderivation functions, as described above, are unique to each conditionalaccess provider. Embodiments of the present invention may utilize avariety of key derivation functions, where the key derivation functionsare secret to each conditional access provider. Key derivation functionsthat are secret one-way functions may provide for strongerauthentication capabilities.

In step 505, the root key is obtained; for example, as the output fromthe key derivation function selected in step 503. The root key, KEY-2,is unique to the conditional access provider to whom the key generationfunction was assigned. By having a shared global root key and a secretkey derivation function for each conditional access provider,embodiments of the present invention avoids the necessity to share theencryption themselves between conditional access providers.

Controlled Device Implementing Authenticated Mode Control

FIG. 6 illustrates a process 600 that can be implemented on a controlleddevice such as STB 120 to receive and process messages from a headend,such as headend 110, to cause the controlled device to change its modeof operation. For example, process 600 can be used to transition STB 120from a mode of receiving content from conditional access provider A(MODE-A) to a mode of receiving content from conditional access providerB (MODE-B).

In step 601, a plurality of messages pertaining to a change of mode tobe effected is received in STB 120. In one embodiment, three messagesare received at STB 120 from headend 110 over the media distributionnetwork 111 and input interface 322. The three messages—MKEY,MAUTHORIZATION, and MREQUEST—can be received at STB 120 in any order.The received messages may be stored in a temporary memory, such asmemory 303, in STB 120 at least until they are processed, for example,according to steps 603-621. The received messages may also be stored innon-volatile memory such as flash memory so that the last receivedmode-related messages are available for use even in the event of areboot of the STB.

MKEY is a message from headend 110 to STB 120 that informs STB 120 ofthe key KEY-3 used for protecting the mode authorization messageMAUTHORIZATION. MAUTHORIZATION includes an authorized mode and a randomstring. In some embodiments, MAUTHORIZATION can also include an epochvalue. MAUTHORIZATION is generally generated by a headend correspondingto the particular STB and conditional access provider, such as headend110. MREQUEST is the message requesting a change of mode. In theembodiment described herein, MKEY, MAUTHORIZATION, and MREQUEST, are allgenerated at the same headend. However, there can be other embodimentsof the present invention in which MKEY, MAUTHORIZATION, and MREQUEST,are not generated at the same location. Example embodiments includeembodiments in which one or more MREQUEST and MAUTHORIZATION messagesare stored in OTP memory of STB 120 at the time of manufacture

In step 603, the root key of a key ladder used for key management in STB120 can be derived. In one embodiment, a global root key that may beshared among a plurality of conditional access providers is input to akey distribution function specific to the conditional access providercorresponding to the requested mode. The output from the key derivationfunction is a key KEY-2 that corresponds to the root key of the keyladder that can be used to access messages from headend 110 with respectto the new conditional access provider. Step 603 is further describedbelow in relation to FIG. 7. The derivation of the root key KEY-2 can beimplemented by modules including the STB key generator module 310 andthe STB key deriver 308 of STB 120.

In step 605, STB 120 obtains a MKEY message. STB 120 can obtain themessages for performing the change in conditional access modes. In someembodiments, the messages may already be received and stored in atemporary memory such as memory 303 or a more permanent form of storagesuch as OTP 306 or storage 305. In some embodiments, step 605 mayinclude a request/response message exchange for STB 120 to request theMKEY message from headend 110.

The MKEY message is, received in general, in encrypted form. In the MKEYmessage, the encryption key KEY-3 would have been encrypted using theroot key KEY-2 at the sender. In step 607, the MKEY message is decryptedto obtain the key KEY-3. The recovery of key KEY-3 from the message MKEYmay be performed by key manager module 340 and the encrypter/decryptermodule 320.

A mode authorization message MAUTHORIZATION that corresponds to the MKEYmessage received in step 605 is obtained in step 609. The MAUTHORIZATIONmessage may have been previously received and stored in a temporarymemory such as memory 303 or a more permanent form of storage such asOTP 306 or storage 305. In some embodiments, step 605 may include arequest/response message exchange for STB 120 to request theMAUTHORIZATION message from headend 110.

The MAUTHORIZATION message is, in general, encrypted by the sender usingthe encryption key KEY-3. In step 611, the MAUTHORIZATION message isdecrypted using the key KEY-3 obtained in step 607. In one embodiment,the decrypted MAUTHORIZATION message includes the value of theauthorized-mode for STB 120, a random value generated at the headend 110which is also included in the corresponding mode request messageMREQUEST, and an epoch value.

In step 613, the epoch value is compared to a corresponding epoch valuemaintained in STB 120. In some embodiments, headend 110 can signal arevocation of the currently authorized-mode by instructing STB 120 toincrease its epoch value. A revocation is intended, in general, to causeSTB 120 to transition into a mode where it is not authorized to receiveprogramming content from any conditional access provider. For example,headend 110 can request STB 120 to increase its locally maintained epochvalue, thereby preventing any previously received mode authorizationmessages from being effective.

If the epoch value in MAUTHORIZATION is greater or equal to the epochstored in STB 120, then the epoch values are considered valid.

In step 615, a corresponding request message MREQUEST is received. Insome embodiments, the MREQUEST message may have been previously receivedand stored in a temporary memory such as memory 303 or a more permanentform of storage such as OTP 306 or storage 305. In some embodiments,step 605 may include a request/response message exchange for STB 120 torequest the MREQUEST message from headend 110. The mode request istypically transmitted by the headend 110 in the clear, i.e., withoutencryption. In step 615, the data items from the MREQUEST message areobtained. For example, the MREQUEST message contains a requested-mode aswell as, in some embodiments, a random value that is also included inthe corresponding MAUTHORIZATION message.

In step 617, the random values from the MREQUEST message and theMAUTHORIZATION messages are compared. If the random values do not match,there can be no transition. If the random values match, then theMREQUEST and MAUTHORIZATION have been verified. For example, thematching of the random strings enables the use of the MAUTHORIZATIONmessage that was sent in encrypted form, to authenticate the MREQUESTmessage that was sent in non-encrypted form.

In step 619, having successfully verified the epoch, if any, and havingverified the random values such as random strings embedded in MREQUESTand MAUTHORIZATION messages, the requested-mode from MREQUEST iscompared with the authorized-mode from MAUTHORIZATION. If therequested-mode and the authorized-mode match, then a request for achange of conditional access modes has been verified and authorized.

In step 621, the STB 120 changes its conditional access mode asspecified in MREQUEST. Further description of implementing the change ofconditional access modes in STB 120 is provided with respect to FIGS. 8and 9.

FIG. 7 illustrates the processing involved in deriving the root keyKEY-2 in step 603, according to one embodiment. In step 701, STB 120obtains its global root key. As described previously, STB 120 can haveits global root key stored in a memory such as OTP memory 306. In someembodiments, the global root key is stored at the time of manufacture,for example, by using a black box key database in the assembly line. Theblack box key database can be provided by a conditional access provideror other key generating authority. In other embodiments, the global rootkey may be stored in STB 120 after the time of manufacture, by insertinga smart card or other pluggable device containing the global root key,or by downloading the global root key to the STB 120 via a securedistribution means such as secure software download.

In step 703, the key derivation function for the conditional accessprovider corresponding to the requested-mode is identified and selected.In one embodiment, the key derivation functions of each conditionalaccess provider are implemented as separate logic blocks implemented inhardware, for example, in STB key deriver 308. Based on the requestedmode, one of the key derivation function logic blocks are selected, forexample, using selector 309. Key derivation functions and theimplementation of key derivation functions are well known. Embodimentsof the present invention can include a variety of key derivationfunctions. In some embodiments, the key derivation functions for one ormore conditional access providers are secret one-way cryptographicfunctions.

In step 705, STB 120 inputs its global root key into the selected keyderivation function for the requested mode. STB 120 receives the rootkey KEY-2 specific to the requested mode and corresponding conditionalaccess provider as the output from the key derivation function. In oneembodiment, for example, the root key is then used to decrypt the MKEYin order to extract key KEY-3.

FIG. 8 illustrates a state machine 800 that can be implemented in acontrolled device, such as STB 120, according to an embodiment of thepresent invention. State machine 800 can be implemented in software,hardware, or using any combination thereof. State machine 800 can beused to ensure the controlled and authenticated changing of modes in STB120. When STB 120 initially comes up (e.g., boots up), for example, whena new STB is installed in a network such as media distribution network100, STB 120 comes up in mode MODE-0 801. In mode MODE-0 801, STB 120 isnot authorized to receive conditional access protected content.

Transition 811 can be triggered upon STB 120 reading a mode request thatrequests a change of mode to MODE-A. As mentioned above, STB 120 mayhave access to a mode request in many ways. For example, a mode requestmay be received from a headend, such as headend 110, or anotherauthorization entity coupled to the distribution network 100. A moderequest may also be created at the time of manufacture and held in amemory, such as OTP memory. Also, in some embodiments a mode request maybe generated by means local to STB 120, such as a software programtriggered by a user or operator action.

Transition 811, causes STB 120 to transition from mode MODE-0 801 tomode MODE-A-TEMP 802, the unverified (or transitional) mode forconditional access provider A. In mode MODE-A-TEMP 802, STB 120 cannotreceive conditional access protected content, but can receive messagesfrom the conditional access provider corresponding to MODE-A, i.e.,conditional access provider A (CA-A). In some embodiments, STB 120 canbe prevented from receiving messages from any other conditional accessprovider than CA-A.

In mode MODE-A-TEMP 802, STB 120 is expecting to receive a modeauthorization from the corresponding conditional access provider, i.e.,CA-A. As noted above, mode authorization messages can be received from aheadend, such as headend 110, in the form of EMM messages. When a modeauthorization message is received it must be decrypted with a secret keythat is generally received in a separate message from the headend. Theseparate message containing the secret key can be decrypted usinganother key which is specific to the corresponding conditional accessprovider. The decrypted mode authorization message generally containsthe authorized-mode, and one or more other values such as a randomnumber and an epoch.

The random number, for example, is generally used to verify that themode authorization message and the mode request originate from the samesource, for example, to reduce the possibility of a mode requestinserted by an attacker having a negative effect on the network. Theepoch can be used as a revocation mechanism, as described above. Therandom number of the mode authorization message is compared to therandom number in the mode request message. If the match is exact, forexample, the random number verification is completed successfully. Theepoch received in the mode authorization message can be compared againstthe epoch held in memory of the STB. In general, it is expected that theepoch of the mode authorization message should be equal to or higherthan the epoch value stored on the STB. Therefore, if the epoch value ofthe STB is equal or lower to the epoch value in the message, then theepoch values are considered verified.

If the verification of at least one of the elements to be verified—forexample, mode value, random number, and epoch—is unsuccessful, then theverification can be considered failed, and transition 812 is invoked totransition the STB to mode MODE-0 801.

If the verification of all the relevant elements that were considered issuccessful, then the verification can be considered successful, andtransition 813 can be invoked to transition STB 120 into a verifiedactive mode, i.e., mode MODE-A 803. In mode MODE-A 803, STB 120 canreceive conditional access protected content.

FIG. 9 shows another embodiment of the present invention. State machine900 illustrates, in addition to what is described with respect to FIG. 8above, a means by which a controlled device such as STB 120 cantransition from one active verified mode to another active verifiedmode.

As described earlier, STB 120 can transition to mode MODE-A 803 which isthe active verified mode for conditional access provider A. If an eventsuch as, changing the network coverage area of CA-B so that it nowoverlaps the network coverage area of CA-A at the location of STB-120,then STB 120 would require reconfiguration in order to receive contentprotected by conditional access provider B. Until such reconfiguration,STB 120 that was last in MODE-A is authorized only to receive contentprotected by conditional access provider A.

To initiate the transition, the current conditional access provider,e.g., CA-A, generates a mode request and mode authorization messageauthorizing CA-A to transition to the active mode for conditional accessprovider B, i.e., MODE-B. When the mode request from CA-A requesting achange to MODE-B, and also the mode authorization from CA-A authorizingthe change to MODE-B, are received, STB 120 can move from mode MODE-A803 through transition 912 to mode MODE-B-TEMP 902. Mode MODE-B-TEMP 902is an unverified (or transitional) mode corresponding to conditionalaccess provider B. In this state, STB 120 cannot receive content such ascable television programming content that is protected by conditionalaccess provider B, but can receive messages.

In another embodiment, when STB 120 is in an active verified mode suchas MODE-A, the current conditional access provider CA-A can send a moderequest and corresponding mode authorization to the STB 120 to cause theSTB to transition to a mode in which no conditional access provider,such as mode MODE-0 801. From mode MODE-0 801, STB 120 can transition toanother active verified mode for any conditional access provider, asdescribed above in relation to FIG. 8.

It should be noted here that embodiments of the present invention canprevent a controlled device from transitioning from one active verifiedmode to another active verified mode directly. Embodiments of thepresent invention also require that the corresponding conditional accessprovider (or another authorizing entity with authority to represent thatconditional access provider) can authorize the transition into itsactive verified mode. For example, in the case of transitioning frommode MODE-A 803 to mode MODE-B 903, the intermediate unverified modeMODE-B-TEMP 902 can be made unavoidable. Also, compared to transitioningstarting from a MODE-0 801 state, transitioning from an active mode suchas MODE-A 803, requires a mode request and a mode authorization totransition to the unverified mode for the next conditional accessprovider.

While in mode MODE-B-TEMP 902, STB 120 can receive a mode request and amode authorization from the new conditional access provider to which STB120 is to transition to, conditional access provider B. STB 120 canmaintain itself in mode MODE-B-TEMP 902 when the mode request from CA-Bis received and it requests a transition to MODE-B. After the modeauthorization message specifying MODE-B is received from CA-B and isdecrypted, the mode request and mode authorization from CA-B can beverified in the same manner as other mode requests and correspondingmode authorizations are verified. If the verification is unsuccessful,STB 120 transitions through transition 113 to mode MODE-0 801. If theverification is successful, then STB 120 transitions to the activeverified mode for conditional access provider B, MODE-B. In MODE-B, STB120 has the capability to receive conditional access protected contentfrom conditional access provider B.

State machine 900 is an example state machine that can be implemented inSTB 120, in one embodiment of the present invention, to facilitate“chaining” of modes or conditional access providers that control STB120. Chaining refers to having the control of STB 120 (for the provisionof conditional access services) pass from one conditional accessprovider to another. For example, STB 120 that is initially in mediadistribution network 100 and in MODE-A can, at some stage, be moved tomedia distribution network 150. In one embodiment, prior todisconnection from media distribution network 100 STB 120 can receivemode request and mode authorization messages from CA-A requesting achange to MODE-B. The request and authorization from conditional accessprovider A, if verified successfully, causes STB 120 to transition intounverified MODE-B-TEMP. When it is moved to the media distributionnetwork 150 and attached, STB 120 may receive mode request and modeauthorization messages from CA-B requesting and authorizing the changeto MODE-B. In another embodiment, STB 120 in MODE-A can, upon beingcoupled to a new media distribution system such as media distributionnetwork 150, request CA-A to send the mode request and modeauthorization messages that will enable STB 120 to transition to a modein which the corresponding mode request and mode authorization from CA-Bcan be processed.

FIGS. 8-9 describe state machines in STB 120 that can implement theteachings of this disclosure in some embodiments. A person of ordinaryskill in the art would recognize that other embodiments of the presentinvention may include modifications to state machines 800 and 900,and/or other state machines.

Other Embodiments

The embodiments described above are primarily those in which eachcontrolled device is assigned a unique global root key. Anotherembodiment of the present invention includes a global root key or rootkey KEY-2 that is common to multiple controlled devices of a particularconditional access provider. Note that a global root key that is commonto multiple controlled devices of a conditional access provider wouldresult in a common root key KEY-2 if the conditional access providermaintains the same key derivation function for all those controlleddevices. When a common root key KEY-2 is available, the headend canbroadcast one message MKEY containing the encryption/decryption keyKEY-3 to be distributed to multiple controlled devices that have acommon root key KEY-2.

Another embodiment includes an encryption/decryption key KEY-3 that iscommon to all controlled devices. In this case, the headend can transmitcommon MKEY and MAUTHORIZATION messages to the controlled devices thathave the common KEY-3. The ability to cause authenticated modetransitions in multiple controlled devices simultaneously cansubstantially facilitate configuration of large service providernetworks.

Yet another embodiment can include controlled devices that have at leastone mode request message written, for example, into its OTP memory atthe time of manufacture. For example, when it is known at the time ofmanufacture or initialization of an STB that the initial conditionalaccess provider would be CA-A, a mode request can be written into itsOTP memory to correspond to that conditional access provider. Then, uponconnecting to a media distribution network, the STB can read theconditional access provider (or corresponding mode) in its OTP andtransition into the unverified mode MODE-A-TEMP, as described inrelation to FIG. 8 above. Subsequently, it can transition to activeverified mode MODE-A after receiving the corresponding modeauthorization message from CA-A.

Another embodiment can have a mode request as well as a correspondingmode authorization message written into a controlled device at the timeof manufacture. For example, a mode request for conditional accessprovider CA-A, as well as a mode authorization for conditional accessprovider CA-A can be stored in the OTP memory 306 of STB 120 at the timeof manufacture. The mode authorization can be stored in OTP memory inencrypted form, encrypted with key KEY-3. Then, when STB 120 is to beactivated, for example, by connecting to media distribution network 111,the key KEY-3 can be received from headend 110 to decrypt the storedmode authorization and cause the change of mode. When STB 120 is coupledto media distribution network 111, headend 110 can send the key KEY-3 toSTB 120 using a key message, such as MKEY, encrypted for example with aderived root key KEY-2 for conditional access provider A.

The embodiments above are described primarily based on symmetric keytechnology, where the encryption and decryption keys are identical.However, embodiments using asymmetric keys are also contemplated. Forexample, in one embodiment, headend key generator 210 in headend 110 cangenerate a pair of keys (e.g., KEY-3-PUBLIC and KEY-3-PRIVATE) in placeof a single key KEY-3. It may then include KEY-3-PRIVATE in thecorresponding MKEY message, and encrypt the corresponding MAUTHORIZATIONmessage using KEY-3-PUBLIC.

The representative functions of the controlled device described hereincan be implemented in hardware, software, or some combination thereof.For instance, processes 800 and 900 can be implemented using computerprocessors, computer logic, ASIC, FPGA, DSP, etc., as will be understoodby those skilled in the arts based on the discussion given herein.Accordingly, any processor that performs the processing functionsdescribed herein is within the scope and spirit of the presentinvention.

CONCLUSION

It is to be appreciated that the Detailed Description section, and notthe Summary and Abstract sections, is intended to be used to interpretthe claims. The Summary and Abstract sections may set forth one or morebut not all exemplary embodiments of the present invention ascontemplated by the inventor(s), and thus, are not intended to limit thepresent invention and the appended claims in any way.

The present invention has been described above with the aid offunctional building blocks illustrating the implementation of specifiedfunctions and relationships thereof. The boundaries of these functionalbuilding blocks have been arbitrarily defined herein for the convenienceof the description. Alternate boundaries can be defined so long as thespecified functions and relationships thereof are appropriatelyperformed.

The foregoing description of the specific embodiments will so fullyreveal the general nature of the invention that others can, by applyingknowledge within the skill of the art, readily modify and/or adapt forvarious applications such specific embodiments, without undueexperimentation, without departing from the general concept of thepresent invention. Therefore, such adaptations and modifications areintended to be within the meaning and range of equivalents of thedisclosed embodiments, based on the teaching and guidance presentedherein. It is to be understood that the phraseology or terminologyherein is for the purpose of description and not of limitation, suchthat the terminology or phraseology of the present specification is tobe interpreted by the skilled artisan in light of the teachings andguidance.

The breadth and scope of the present invention should not be limited byany of the above-described exemplary embodiments, but should be definedonly in accordance with the following claims and their equivalents.

1. A device comprising: at least one processor; a plurality of keyderivation functions configured to be executed by the at least oneprocessor, wherein each key derivation function of the plurality of keyderivation functions includes an assigned mode value corresponding toone of a plurality of operating modes of the device, and wherein saideach key derivation function is configured to take as input a globalroot key and generate a root key specific to the assigned mode value. 2.The device of claim 1, further comprising: a mode controller configuredto: recover a mode change instruction from an encrypted message usingthe generated root key; and change an operating mode of the device basedupon the recovered mode change instruction.
 3. The device of claim 2,further comprising: a non-volatile memory configured to store the globalroot key.
 4. The device of claim 2, wherein the device is a set-top box.5. The device of claim 2, wherein the device is a system-on-a-chip for aset-top box.
 6. The device of claim 1, further comprising: a selectorconfigured to select one key derivation function from the plurality ofkey derivation functions, wherein the assigned mode value of the one keyderivation function matches a received requested mode value.
 7. A methodfor changing an operating mode of a device from a current mode,comprising: selecting a target key derivation function from a pluralityof key derivation functions, wherein the target key derivation functioncorresponds to a target mode, and wherein the target mode is one of aplurality of operating modes of the device; generating a target root keyby providing a global root key as input to the target key derivationfunction; and changing the operating mode in the device from the currentmode to the target mode using the generated target root key.
 8. Themethod of claim 7, wherein the changing step comprises: using the targetroot key to recover a decryption key from a key distribution message;and using the recovered decryption key to decrypt a requested modechange message.
 9. The method of claim 7, further comprising: receivinga mode change request from an entity external to the device, wherein thereceived mode change request includes the target mode.
 10. The method ofclaim 9, wherein the mode change request is generated by a conditionalaccess provider.
 11. A computer readable storage medium havinginstructions stored thereon that, when executed by a processor, causethe processor to perform a method for changing an operating mode of adevice, wherein the method comprises: selecting a target key derivationfunction from a plurality of key derivation functions, wherein thetarget key derivation function corresponds to a target mode, and whereinthe target mode is one of a plurality of operating modes of the device;generating a target root key by providing a global root key as input tothe target key derivation function; and changing the operating mode inthe device from the current mode to the target mode using the generatedtarget root key.
 12. The computer readable storage module of claim 11,wherein the changing step comprises: using the target root key torecover a decryption key from a key distribution message; and using therecovered decryption key to decrypt a requested mode change message. 13.The computer readable storage module of claim 11, wherein the methodfurther comprises: receiving a mode change request from an entityexternal to the device, wherein the received mode change requestincludes the target mode.